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Abstract 

The  increasing  use  of  software  in  safety  critical  systems  en¬ 
tails  increasing  complexity,  challenging  the  safety  of  these 
systems.  Although  formal  specifications  of  real-life  systems 
are  orders  of  magnitude  simpler  than  the  system  implemen¬ 
tations,  they  are  still  quite  complex.  It  is  easy  to  over¬ 
look  problems  in  a  specification,  ultimately  compromising 
the  safety  of  the  implementation. 

Since  it  is  error-prone  and  time  consuming  to  check  large 
specifications  manually,  mechanical  support  is  needed.  The 
challenge  is  to  find  the  right  combination  of  deductive  po¬ 
wer  (i.e.,  how  rich  a  logic  and  what  theories  are  decided)  and 
efficiency  to  complete  the  verification  in  reasonable  time.  In 
addition,  it  must  be  possible  to  explain  why  a  proof  fails. 

As  an  initial  approach  to  solving  this  problem,  we  have 
adapted  the  Stanford  Validity  Checker  (SVC),  a  highly  ef¬ 
ficient,  general-purpose  decision  procedure  for  quantifier- 
free  first-order  logic  with  linear  arithmetic,  to  check  the 
consistency  of  specifications  written  in  Requirements  State 
Machine  Language  (RSML).  We  have  concentrated  on  a 
small  but  complex  part  of  version  6.04a  of  the  specificar 
tion  of  the  (air)  Traffic  alert  and  Collision  Avoidance  System 
(TCAS II).  SVC  was  extended  to  produce  a  counter-example 
in  terms  of  the  original  specification. 

The  efforts  discovered  an  undesired  inconsistency  in  the 
specification,  which  the  maintainers  of  the  specification  in¬ 
dependently  discovered  and  subsequently  fixed  in  the  most 
recent  version. 

The  case  study  demonstrates  the  practicality  of  uncover¬ 
ing  problems  in  real-life  specifications  with  a  modest  effort, 
by  selective  application  of  state-of-the-art  formal  methods 
and  tools.  The  logic  of  SVC  was  sufficiently  expressive  for 
the  properties  that  we  checked,  but  more  work  is  needed  to 
extend  the  class  of  formulae  that  SVC  decides  to  cover  the 
properties  found  in  other  parts  of  the  TCAS  II  specification. 

*The  research  was  supported  by  the  Defense  Advanced  Research 
Projects  Agency  under  contract  number  E276,  and  by  National  Sci¬ 
ence  Foundation  under  NSF  CAREER  grant  CCR-9624324, 
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1  introduction 

Software  plays  an  increasingly  important  role  in  the  imple¬ 
mentation  of  safety  critical  systems.  For  example,  avionics 
systems  are  becoming  more  dependent  upon  large  amounts 
of  embedded  software  to  reduce  cost  and  increase  maintain¬ 
ability.  This  trend  is  evident  in  the  proposed  Integrated 
Modular  Avionics  (IMA)  standard  [15]. 

Unfortunately,  the  increase  in  software  functionality  also 
entails  an  increase  in  complexity,  which  makes  assuring  the 
safety  of  such  systems  challenging.  The  problem  is  aggra¬ 
vated  by  the  fact  that  many  safety-critical  systems  consist  of 
several  parallel  components  which  are  subject  to  real-time 
constraints. 

Formal,  high-level  specifications  for  system  software  can 
help  increase  confidence  in  a  system  by  revealing  inconsis¬ 
tencies  and  gaps  in  the  system  design.  The  implementation 
can  then  be  systematically  reviewed  for  conformance  with 
the  specification.  This  approach  has  been  successfully  ap¬ 
plied  in  several  software  projects  [4].  Examples  include  the 
application  of  tables  (Parnas  et  al.)  [18]  to  the  specification 
and  validation  of  a  nuclear  power  plant  shutdown  system 
and  the  application  of  the  Requirements  State  Machine  Lan¬ 
guage  (RSML)  to  the  specification  of  the  (air)  Traffic  alert 
and  Collision  Avoidance  System  (TCAS  II)  [14]. 

Although  a  formal  specification  is  orders  of  magnitude 
simpler  than  the  actual  system  implementation,  it  can  still 
be  quite  complex.  It  is  easy  to  overlook  problems  in  a  spec¬ 
ification  that  may  ultimately  compromise  the  safety  of  the 
implementation.  Indeed,  it  has  been  noted  that  errors  in 
the  implementation  can  frequently  be  traced  to  errors  in  the 
specification.  It  has  also  been  shown  that  specification  er¬ 
rors  are  more  likely  than  implementation  errors  to  be  safety 
critical  [9]. 

Jaffe  et  al.  have  identified  two  properties  of  specifica¬ 
tions  that  turn  out  to  be  particularly  related  to  safety  and 
accidents  [13]:  Completeness  which  ensures  that  there  is  a 
specified  behavior  for  every  input;  and  consistency  which  en¬ 
sures  that  the  system  is  free  from  confiicting  requirements 
and  undesired  non-determinism. 

Checking  consistency  and  completeness  of  a  realistic  spe¬ 
cification  is  nontrivial.  Manual  checking  is  tedious,  error- 
prone,  and  infeasible  for  large  specifications.  Recently,  au¬ 
tomatic  checking  based  on  binary  decision  diagrams  (BDDs) 
has  been  partially  successful.  However,  since  BDDs  are  used 
as  a  decision  procedure  for  propositional  logic,  they  can  not 
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reason  about  arithmetic  and  inequalities,  as  is  often  required 
when  etnalyzing  software  that  deals  with  physical  systems. 

Many  of  the  inequalities  in  TCAS  II  can  be  handled  using 
BDDs  by  replacing  the  inequalities  with  Boolean  variables. 
However,  a  number  of  the  inequalities  need  to  be  interpreted 
and  will  produce  spurious  error  reports  when  checked  using 
BDDs.  For  instance,  using  BDDs  it  is  not  possible  to  de¬ 
termine  that  X  <  0  A  a;  >  600  is  false  for  some  variable  x. 
Heimdahl  et  al.  observe  that  manually  checking  each  error 
report  is  very  labor  intensive  [9]  and  infeasible  for  large  spec¬ 
ifications.  Anderson  et  al.  note  the  inability  of  SMV  to  deal 
efficiently  with  the  multiplication  found  in  TCAS  II  [1]. 

Hoover  and  Chen  [12]  use  a  generalization  of  BDDs  called 
finite  decision  diagrams  (FDDs)  to  check  consistency  and 
completeness  in  the  Thblewise  tool.  In  contrast  to  BDDs 
with  their  binary  branching,  FDDs  allow  finite  branching 
to  represent  finite  valued  variables.  However,  this  is  not 
sufficient  to  deal  with  the  cases  illustrated  by  the  simple 
example  above. 

Another  approach  is  to  use  a  more  general  theorem¬ 
proving  system,  such  as  PVS  [17].  Initial  experiments  check¬ 
ing  properties  of  TCAS  II  were  partly  unsuccessful  due  to 
inefficiencies  in  an  earlier  version  of  PVS  [8].  In  general, 
the  decision  procedures  are  embedded  within  the  prover  and 
are  therefore  hard  to  access  from  an  external  specification 
checker.  Often,  they  can  only  be  accessed  by  generating, 
parsing,  and  type  checking  specifications  in  the  theorem 
prover.  This  introduces  significant  overhead  when  check¬ 
ing  a  large  number  of  properties.  Furthermore,  integrating 
and  customizing  a  theorem  prover  in  a  special  purpose  spec¬ 
ification  checking  tool  is  hard,  due  to  the  large  amount  of 
front-end  proof-management  software.  Finally,  although  an 
unprovable  theorem  prover  subgoai  can  implicitly  provide 
some  hints  as  to  why  a  property  is  not  true,  it  is  not  able  to 
provide  the  user  with  localizing  and  debugging  information 
in  the  form  of  an  error  trace. 

The  challenge  is  to  find  the  right  combination  of  deduc¬ 
tive  power  (how  rich  a  logic  and  what  theories  are  deci¬ 
ded)  and  efficiency  (completion  of  verification  in  reasonable 
time).  Unfortunately,  deductive  power  and  efficiency  are 
usually  inversely  related.  With  too  little  deductive  power, 
a  tool  may  generate  an  inordinate  number  of  spurious  error 
reports  since  the  proof  procedure  can  not  sufficiently  inter¬ 
pret  operators  in  the  formulae.  With  too  much  deductive 
power,  the  verification  may  not  terminate  in  an  acceptable 
time  period,  since  manual  interaction  is  required  in  carrying 
out  the  verification. 

In  addition,  it  is  important  that  counter-examples  be 
presented  to  the  user  in  the  context  of  the  original  problem. 
In  our  experience,  interpreting  counter-example  output  and 
casting  it  in  terms  of  the  specification  property  to  be  verified 
is  time  consuming. 

As  an  initial  approach  to  solving  these  problems,  we 
adapted  the  Stanford  Validity  Checker  (SVC)  [3],  a  general- 
purpose  decision  procedure  for  quantifier-free  first-order  lo¬ 
gic  with  linear  arithmetic,  to  check  the  consistency  of  spec¬ 
ifications  written  in  Requirements  State  Machine  Language 
(RSML).  We  modified  SVC  to  produce  a  counter-example 
in  terms  of  the  original  specification,  which  enables  a  user 
to  locate  the  corresponding  flaw  in  the  original  specification 
when  an  inconsistency  is  discovered. 

SVC’s  capabilities  come  closest  to  those  of  the  General 
Validity  Checker  (GVC)  [2],  which  is  used  to  check  consis¬ 
tency  and  completeness  properties  of  Software  Cost  Reduc¬ 
tion  (SCR)  tabular  notations  [10].  In  contrast  to  SVC  with 
its  tight  integration  of  decidable  theories  in  a  monolithic 


tool,  GVC  combines  a  collection  of  third  party  tools  for 
propositional  rewriting,  tautology  checking,  amd  full  Pres- 
burger  arithmetic.  Given  a  property,  simple  propositional 
rewriting  is  first  tried.  If  it  does  not  succeed,  tautology 
checking,  and  later  a  Presburger  arithmetic  procedure  is  ap¬ 
plied  if  needed.  SVC  does  not  support  general  quantification 
found  in  full  Presburger  arithmetic,  but  allows  uninterpreted 
function  symbols  and  supports  congruence  closure.  That  is, 
if  a  =  6  then  f{a)  =  f{b).  More  experience  is  needed  to 
determine  the  usefulness  of  this  feature  for  checking  safety 
critical  specifications.  On  the  other  hand,  it  is  our  experi¬ 
ence  that  unlimited  quantification  is  not  common  in  safety 
critical  specifications  and  support  for  full  Presburger  arith¬ 
metic  is  therefore  not  needed. 

We  used  SVC  to  check  the  consistency  of  a  part  of  ver¬ 
sion  6.04a  of  the  TCAS  II  specification,  written  in  RSML. 
Our  efforts  uncovered  an  inconsistency..  We  confirmed  with 
the  maintadners  of  the  specification  that  this  inconsistency 
was  a  true  problem  in  the  specification.  It  was  found  inde¬ 
pendently  by  them  and  fixed  as  part  of  a  general  revision  in 
version  7.0  of  the  TCAS  H  specification  [7].  This  correction 
was  verified  by  reapplying  our  tools  to  the  new  specification. 

The  following  sections  describe  the  tools  and  their  ap¬ 
plication  to  TCAS  H.  The  Stanford  Validity  Checker  is  de¬ 
scribed  in  Section  2  and  Section  3  describes  RSML.  An 
overview  of  TCAS  II  is  given  in  Section  4  and  the  approach 
to  verification  is  illustrated  in  Section  5.  A  discussion  is 
provided  in  Section  6. 

2  Stanford  Validity  Checker 

The  Stanford  Validity  Checker  (SVC)  [3]  is  a  decision  pro¬ 
cedure  for  quantifier-free  first-order  logic  and  uses  an  al¬ 
gorithm  similar  to  the  algorithms  by  Shostak  [20,  19]  and 
Nelson-Oppen  [16]. 

The  TCAS  relevant  logic  that  SVC  decides  includes: 

•  the  usual  Boolean  connectives] 

•  equality  on  terms; 

•  uninterpreted  function  symbols^  such  as:  /,  ^,  for  which 
no  previous  knowledge  is  asserted; 

•  congruence  closure,  so  that  if  x  =  j/,  then  we  know 
that  fix)  =  f{y)] 

•  distinct  constants,  which  include  the  Boolean  truth 
values,  the  rational  numbers,  and  a  form  of  enumer¬ 
ated  constants  (preceded  with  @).  As  an  example, 
the  distinct  constant  ^  On-Ground  is  not  equal  to  any 
other  constant; 

•  linear  arithmetic,  with  the  rational  numbers,  the  usual 
inequalities:  <,  >,  >,  <,  and  expressions  formed  by 
addition  and  linear  multiplication  (i.e.,  constants  mul¬ 
tiplied  by  variables);  1/2  ♦  x  -h  3/4  ♦  y]  and 

•  conditionals  in  the  form  of  if-then-else  expressions,  e.g. , 
if  a  then  1  else  2, 

and  combinations  of  these.  Furthermore,  SVC  supports  in¬ 
terpreted  theories  such  as  records  and  (infinite)  stores.  It 
also  supports  bitvectors,  which  have  been  shown  to  be  use¬ 
ful  in  hardware  verification.  SVC  is  modular  in  its  imple¬ 
mentation  and  facilitates  easy  extensions  of  new  interpreted 
theories. 

Given  a  formula,  SVC  will  decide  the  validity  of  the  for¬ 
mula  and  either  return  with  “OK”  or  a  counter-example.  A 


Transit  ion(s): 


Potential-Threat 


Other-TVaific 


Location:  Other- Aircraft  >  Intruder-StatuSs.154 
TVigger  Event:  Air-Status-Evaluated-Evente-396 
Condition: 


A 

N 

D 


Alt-Reportings_i4g  in  state  Lost 
RA-Mo  de-Cancelledm- 1 6 1 
Alt-Reporting8_i43  in  state  No 
Other-Bearing- ValidY_i33  =  TYue 
Other-Range-Validy.iso  =  True 

Potential-Threat-Range-Testni_289 

Potentiat-Threat-Conditionni-288 _ 

Proximate-TVaffic-Conditionin-292 

Threat-Conditionm_305 _ 

PT-Timer8_24o  in  state  0 

Other- Air-StatuSg.!  48  in  state  On-Ground 


Output  Action:  Intruder-Status-Evaluated-Evente^sge 


Figure  1:  A  transition  definition  from  TCAS  II  with  the  guarding  condition  expressed  as  an  and/or  table.  T  denotes  logical 
true  and  F  denotes  false. 


counter-example  is  a  conjunction  of  simple  predicates  which 
is  (1)  satisfiable  and  (2)  implies  the  negation  of  the  original 
formula. 

SVC  is  implemented  in  0-1-4*  and  care  has  been  taken 
to  make  it  efficient.  It  has  been  applied  to  a  number  of 
large  hardware  verification  examples,  including  verification 
of  FLASH  [21]. 

3  Requirements  State  Machine  Language  (RSML) 

RSML  was  developed  as  a  requirements  specification  lan¬ 
guage  for  embedded  systems.  The  language  is  based  on 
hierarchical  finite  state  machines  and  is  similar  to  David 
Harel’s  Statecharts  [5,  6].  As  illustrated  in  Figure  2,  RSML 
supports  parallelism,  hierarchies,  and  guarded  transitions 
which  originated  in  Statecharts.  Transition  guards  are  ex¬ 
pressed  as  e[c]/ a  where  e  is  the  trigger  event  that  enables  a 
transition,  c  is  a  guarding  condition  that  determines  under 
which  conditions  the  transition  can  be  taken,  and  a  is  the 
set  (possibly  empty)  of  events  that  are  generated  as  cictions 
when  the  transition  is  taken. 

In  real-life  specifications  such  as  TCAS  II,  the  guarding 
conditions  required  to  accurately  capture  the  requirements 
are  often  complex.  The  propositional  logic  notation  tradi¬ 
tionally  used  to  define  these  conditions  do  not  scale  well 
to  complex  expressions  and  quickly  become  unreadable.  To 
overcome  this  problem,  guarding  conditions  are  expressed  in 
a  tabular  representation  of  disjunctive  normal  form  (DNF) 
called  and/or  tables  (see  Figure  1  for  an  example  from  the 
TCAS  II  requirements).  The  far-left  column  of  the  and/or 
table  lists  the  logical  phrases.  Each  of  the  other  columns  is  a 
conjunction  of  those  phrases  and  contcuns  the  logical  values 
of  the  expressions.  If  one  of  the  coltunns  is  true,  then  the 
table  evaluates  to  true.  A  column  evaluates  to  true  if  all  of 
its  elements  are  true.  A  dot  denotes  “don’t  care.”  The  table 
evaluates  to  false  if  all  of  the  columns  are  false. 

To  further  improve  readability,  many  other  syntactic  con¬ 
ventions  were  introduced  in  RSML.  For  example,  expres¬ 
sions  used  in  the  predicates  can  be  defined  as  mathemat¬ 
ical  functions  (e.g.,  Other-Tracked- Altf.343),  and  familiar 


Figure  2:  An  excimple  of  a  hierarchical  state  machine. 


and  frequently  used  conditions  can  be  defined  as  macros 
(e.g.,  Threat-Conditionm-sos)*  A  macro  is  simply  a  named 
and/or  table  defined  elsewhere  in  the  document.  The  sub¬ 
script  is  used  to  indicate  the  type  of  an  identifier  (f  for  func¬ 
tions,  m  for  macros,  and  v  for  variables)  and  gives  the  page 
number  in  the  TCAS  II  requirements  document  where  the 
identifier  is  defined.  Naturally,  the  state  machine  in  a  red 
system  is  seldom  as  simple  as  in  Figure  2.  As  an  example  of 
a  realistic  model,  a  part  of  the  state  machine  modeling  an 
intruding  aircraft  in  TCAS  II  is  shown  in  Figure  3.  See  [14] 
for  a  detailed  description  of  the  graphical  notation. 

RSML  specifications  are  required  to  be  deterministic  and 
have  a  well-defined  behavior  for  all  inputs.  A  number  of 
criteria  must  be  satisfied  by  a  specification  to  guarantee  this 
[9].  In  particular,  two  properties  must  be  satisfied  locally  by 
transitions  out  of  a  state: 

1.  Consistency:  Every  pair  of  transitions  out  of  the  same 
state  and  with  the  same  trigger  event  must  have  mu¬ 
tually  exclusive  guarding  conditions;  exactly  one  of 
these  transitions  can  be  taken  at  any  time.  This  can 
be  shown  by  pairwise  conjuncting  the  guarding  condi¬ 
tions  on  transitions  triggered  by  the  same  event  out  of 
a  state  and  show  that  the  conjunction  forms  a  contrar 
diction; 


Figure  3:  RSML  model  of  an  intruding  aircraft.  The  guarding  conditions  axe  specified  separately  and  are  therefore  not 
shown.  The  circles  marked  C  denote  conditional  entry  points.  For  instance,  in  state  machine  Sense,  the  condition  specifies 
the  selection  of  Climb  or  Descend. 


CAS 


Figure  4:  Collision  Avoidance  Subsystem  (highest  level). 

2.  Completeness:  The  disjunction  of  the  guarding  condi¬ 
tions  must  form  a  tautology.  This  ensures  that  there 
is  alwa3rs  a  transition  to  take. 

It  was  not  possible  to  check  completeness  of  the  guarding 
conditions  in  TCAS  II,  since  the  creators  of  the  TCAS  II 
specification  implicitly  assume  a  self-loop  in  the  specification 
when  no  guarding  condition  is  satisfied  (i.e.,  if  no  transition 
is  enabled  in  a  state,  the  automaton  remains  in  that  state). 
The  work  described  in  this  paper  has  therefore  focused  on 
the  task  of  verifying  consistency. 

4  Testbed  Specification 

To  introduce  the  reader  to  our  case  study,  we  provide  a  short 
overview  of  TCAS  II. 

4.1  TCAS  II 

TCAS  is  a  family  of  airborne  devices  that  function  indepen¬ 
dently  of  the  ground-based  air  traffic  control  (ATC)  system 
to  provide  collision  avoidance  protection  for  commercial  air¬ 
craft  and  larger  aircraft.  TCAS  II  provides  traffic  advisories 
and  recommended  escape  maneuvers  (resolution  advisories) 
in  a  vertical  direction  to  avoid  aircraft  collisions. 

We  have  focussed  on  the  part  of  the  Collision  Avoidance 
Subsystem  (CAS)  in  TCAS  II  that  classifies  intruding  air¬ 
craft  as  Other-Traffic^  Proximate-Traffic,  Potential- Threat, 
or  Threat 

CAS:  The  highest  level  CAS  state  machine  is  shown  in 
Figure  4.  At  this  level,  CAS  is  either  on  or  off;  if  it  is  on,  it 
may  be  either  fully  operational  or  in  standby  mode. 

In  the  CAS  logic,  the  states  of  three  components  are 
modeled:  own  aircraft,  other  aircraft,  and  ground  radar  star 
tions.  We  focus  on  the  specification  of  other  aircraft. 

Other- Aircraft:  The  state  machines  defining  how  an  in¬ 
truding  aircraft  is  modeled  in  TCAS  II  can  be  seen  in  Fig¬ 
ure  3.  The  guarding  conditions  are  specified  separately.  In 
short,  the  top-level  state  machine  reflects  whether  a  partic¬ 
ular  Other- Aircraft  is  currently  being  tracked  or  not. 


The  Intruder- Status  state  within  Tracked  reflects  the  cur¬ 
rent  classification  of  Other-Aircraft  (Other- Traffic,  Proxi¬ 
mate-Traffic,  Potential- Threat,  and  Threat).  When  an  in¬ 
truder  is  classified  as  a  threat,  a  two-step  process  is  used  to 
select  a  Resolution  Advisory  (RA).  The  first  step  is  to  select 
a  sense  (Climb  or  Descend).  Based  on  the  range  and  altitude 
tracks  of  the  intruder,  the  CAS  logic  models  the  intruder’s 
path  until  Closest  Point  of  Approach  (CPA).  The  CAS  logic 
computes  the  predicted  vertical  separation  for  both  climb 
and  descend  maneuvers,  and  selects  the  sense  that  provides 
the  greater  vertical  separation. 

The  second  step  in  selecting  a  RA  is  to  select  the  strength 
of  the  advisory.  The  least  disruptive  vertical  rate  maneuver 
that  will  still  achieve  safe  separation  is  selected.  For  a  more 
complete  description  of  TCAS  II  and  how  it  was  modeled 
using  RSML,  the  reader  is  referred  to  [14]. 

4.2  Range  Test 

Based  on  experience  from  the  definition  of  the  TCAS  II  spec¬ 
ification,  we  decided  to  focus  our  effort  on  the  transitions  be¬ 
tween  the  states  Threat,  Potential-Threat,  Proximate- Traffic, 
and  Other- Traffic.  The  guarding  conditions  of  these  tran¬ 
sitions  involve  some  of  the  most  complex  interactions  and 
include  a  large  number  of  inequalities  and  two  non-linear 
expressions.  To  illustrate,  the  guarding  conditions  of  the 
transitions  from  Proximate- Traffic  to  Potential- Threat  and 
from  Proximate- Traffic  to  Other-Traffic  and  the  relevant 
macros  are  shown  in  Appendix  C.  One  of  these  macros 
is  the  macro  Potential-Threat- Range-Test  as  shown  in  Fig¬ 
ure  5.  Note  that  it  has  a  non-linear  expression  in  the  first 
row  and  a  number  of  linear  inequalities.  The  expressions 
HITA,  DMODTA,  and  TRTHRTA  are  look-up  tables  that 
return  a  constant  value  depending  on  the  system  state.  The 
abbreviation  TA  URTA  is  a  function  that  for  some  cases  re¬ 
turns  an  expression  which  is  non-linear. 

5  Verifying  Properties  of  TCAS  II 
5.1  Approach 

We  focused  on  checking  the  transitions  out  of  the  Threat,  Po¬ 
tential-Threat,  Proximate-Traffic,  and  Other- TYaffic  states, 
as  shown  in  Figure  3.  For  the  Threat  state  we  checked  the 
consistency  between  pairs  of  transitions  going  out  of  the 
Passed  and  Failed  states.  From  Failed,  transitions  are  pos¬ 
sible  to  Passed,  Potential- Threat,  and  Other-Traffic.  From 
Passed,  transitions  are  possible  to  Failed,  Potential-Threat, 
and  Other-Traffic.  The  transitions  to  the  latter  two  are  in¬ 
dicated  by  the  transitions  from  the  boundary  of  Threat 

In  our  initial  experiments,  we  used  a  textual  version  of 
RSML  and  an  RSML  to  PVS  translator  that  Czerny  et  al. 
constructed  in  a  previous  effort  [8].  The  proof  obligation  was 
expanded  out  in  PVS  and  pass^  on  to  SVC  for  verification, 
using  a  translator  from  PVS  to  SVC  previously  constructed 
at  Stanford.  The  counter-example  was  interpreted  manually 
in  terms  of  the  RSML  definitions. 

As  shall  be  described  below,  the  first  discrepancies  were 
quickly  detected.  However,  the  overall  verification  required 
manu^  intervention  to  direct  the  proof^  and  the  proof  obli¬ 
gations  were  relatively  large  and  slow  to  check  in  PVS  due 
to  lack  of  structure  sharing  of  formulae.  Also,  manually  pre¬ 
senting  the  counter-examples  in  RSML  format  in  the  context 
of  the  TCAS  II  specification  was  very  time  consuming. 

^This  could  be  automated  by  writing  an  automated  strategy  in 
PVS. 


Macro:  Potential-Threat-Range-Test 
Definition: 


OR 


Other-Tracked-Rangef.347  *  Other-Tracked-Range-Ratef.348  <  HITA 

"t" 

Other-TVacked-Range-Ratef.348  >  10  ft/s(RDTHaTA) 

F 

T 

Other-TVacked-Rangef.347  <  DMODTA 

T 

TAURTA  <  TRTHRTA 

“t" 

Figure  5:  The  macro  Potential- Threat- Range- Test 


For  the  examples  we  tried,  we  were  able  to  carry  out 
the  verification  with  two  trivial  substitutions  for  the  expres¬ 
sions  involving  non-linear  multiplication  and  division  with 
uninterpreted  functions.  We  therefore  decided  to  use  SVC 
directly  in  the  verification  and  construct  a  prototype  verifi¬ 
cation  tool  based  on  SVC. 

5.2  The  Prototype  Tool 

The  prototype  verification  tool,  Analyzer,  mechanizes  the 
process  of  expanding  formulae,  invoking  SVC,  and  display¬ 
ing  the  counter-example  in  a  format  that  is  understan^ble 
to  the  RSML  engineer.  The  tool  is  written  in  Lisp  and  con¬ 
nects  to  SVC  using  a  foreign  function  interfiu:e. 

Verification  using  the  tool  is  done  as  follows.  Selected 
parts  of  the  TCAS  II  specification,  represented  in  an  ASCII 
version  of  RSML  (see  Appendix  A  for  an  example),  are 
parsed  and  a  database  of  the  transitions  and  definitions  is 
created.  Next,  on  the  users  request,  two  guarding  conditions 
to  be  checked  for  consistency,  Ei  and  E2,  axe  expanded. 
This  process  involves  recursively  expanding  all  macro  refer¬ 
ences  in  the  guarding  conditions.  The  consistency  property 
is  then  generated  as  A  E2). 

Of  the  two  main  types  of  abstractions  in  RSML,  macros 
and  functions,  we  chose  to  leave  functions  undefined,  where¬ 
as  we  expanded  all  macros  from  the  beginning.  Further¬ 
more,  we  substituted  non-linear  expressions  with  variables. 
This  policy  seems  to  work  well.  First,  in  the  parts  we  looked 
at,  the  TCAS  II  specification  is  written  so  that  it  will  be 
well-formed  regardless  of  the  details  of  function  definitions. 
To  illustrate,  we  let  the  function  TAURTA  remain  unex¬ 
panded  in  the  Potential-Threat-Range- Test  macro  shown  in 
Figure  5,  and  we  substituted  the  non-linear  multiplication 
in  the  first  line  with  a  variable.  Second,  expanding  all  macro 
references  did  not  in  most  cases  significantly  affect  the  com¬ 
plexity  of  the  proof.  However,  expanding  out  all  macros  may 
in  some  cases  result  in  large  formulae  that  require  a  signifi¬ 
cant  number  of  computations  to  verify.  Fortunately,  in  some 
instances  it  may  stiU  be  possible  to  establish  consistency  by 
selectively  expanding  some  of  the  macro  references  and  at¬ 
tempting  the  verification  again.  Our  method  can  easily  be 
extended  to  adopt  such  a  scheme. 

After  the  construction  of  the  formula  is  completed,  SVC 
is  called  to  decide  it.  SVC  may  return  “valid”,  indicat¬ 
ing  that  no  problems  were  found.  More  often,  it  returns 
a  counter-example.  At  this  point,  Analyzer  traces  through 
the  two  transition  tables  and  recursively  dependent  macro 
tables  to  determine  which  tables  had  to  evaluate  to  true  (or 
false)  in  the  counter-example  context  in  order  for  both  tran¬ 
sition  tables  to  be  true.  In  effect.  Analyzer  is  determining 
the  localized  information  that  explains  the  coimter-example 
in  terms  of  RSML  tables.  The  truth  value  of  a  table  is  deter¬ 


mined  by  evaluating  the  predicates  at  the  leftmost  column  of 
the  table  in  the  context  of  the  counter-example.  Predicates 
can  evaluate  to  true,  false,  or  no  value '(if  the  truth  value  of 
the  predicate  can  not  be  determined  in  the  counter-example 
context).  The  tables  whose  truth  values  are  involved  in  the 
counter-example  are  then  pretty  printed  along  with  the  SVC 
counter-example  translated  into  RSML  terms. 

As  an  illustration,  consider  the  partial  output  of  the  tool 
from  checking  consistency  between  two  transitions  Proxi¬ 
mate-Traffic  to  Potential- Threat  and  Proximate-Traffic  to 
Other- Traffic  as  shown  in  Figiire  6.  The  output  first  lists  the 
conditions  in  the  counter-example  imder  which  the  guarding 
conditions  of  the  transitions  axe  simultaneously  true.  The 
relevant  tables  are  then  listed.  For  tables  that  axe  true  (e.g., 
tables  for  the  transitions),  the  column  that  is  satisfied  is 
indicated  by  an  arrow  directly  underneath  it.  The  counter¬ 
example  assertions  satisfying  the  column  are  specified  to  the 
right  of  the  rows  (an  arrow  indicates  a  macro  reference).  For 
tables  that  axe  false,  the  counter-example  assertions  falsify¬ 
ing  each  column  are  indicated  in  parenthesis  to  the  right  of 
the  rows. 

The  first  table  in  Figure  6  evaluates  to  true  since  the 
fourth  column  (disjunct)  is  true  in  the  counter-example  con¬ 
text.  The  column  represents  a  conjunction  of  equalities  and 
a  macro  M_POTENTIAL.THREAT  JUNGE.TEST,  all  of  which  have 
to  be  false.  Since  MJPaTENTIAL_THREAT_RANGE_TEST  must 
evaluate  to  false,  the  macro  is  then  listed.  It  is  ftilse  since  the 
first  inequality  is  false  and  the  second  is  true.  This  causes 
both  disjuncts  of  the  table  to  be  false.  The  full  error  report 
is  illustrated  in  Appendix  B. 

5.3  Results 

Initially,  almost  all  of  the  pairs  of  transitions  that  we  tested 
produced  counter-examples.  It  turned  out  that  some  of 
these  were  due  to  missing  information  regarding  the  global 
state.  Two  invariants  were  added,  and  the  analyses  were 
rerun. 

Out  of  19  pairs  of  transitions  analyzed,  we  found  6  dis¬ 
crepancies.  The  discrepancies  were  given  to  the  maintainers 
of  TCAS  II,  who  reported  that  5  of  these  were  due  to  a 
difference  in  interpretation  of  the  semantics:  in  their  view, 
transitions  out  of  a  super-state  have  higher  priority  than 
transitions  that  originate  in  its  sub-states.  However,  the 
analysis  of  the  padr  of  transitions  shown  in  Appendix  B  re¬ 
vealed  a  non-determinism  in  the  specification.  This  is  the 
problem  that  was  found  independently  by  the  maintainers  of 
the  TCAS  II  specification.  We  have  verified  the  correction 
in  version  7.0  using  Analyzer. 

Although  the  violation  of  consistency  documented  in  Ap¬ 
pendix  B  is  relatively  simple,  the  advantage  of  using  a  pow¬ 
erful  decision  procedure  such  as  SVC  is  indirectly  realized  in 


Tranaitionl :  ILPROXIMATE.lRAFFIC.TO.POTEim AL«THREAT[] 
Tranaition2 :  M_PROXIMATE_TRAFFIC^*ro^OTHER_TRAFFIC  [] 

CODHTER-EX AMPLE 

1)  (S_ALT_REPORTIHG  «  «S_H0) 

2)  (HOT  (S_PT_TIMER  =  CS.PT.O) 

3)  (NOT  (PAIRl  <=  F_H1TA[])) 

4)  (F.OTHER_TRAC»ED_RAHGE_RATEa  >  10) 

6)  (HOT  (V.OTHER_BEARIHG_VALID  «  OBOOL.CTRUE)) 

6)  (HOT  (V.PRE7_RA_IHHIBIT  =  OBOOL.CTRUE) ) 

7)  (S.AUTO.SL  -  0S«ASL^2) 


TABLE:  M_PROXIMATE_TRAFFIC_TO .POTENTIAL .THREAT []  /  TRUE  *** 


(S.ALT.REPQRTIHG  ■  OS.TES)  F  T  F  F  T  ;1 

(V.OTHER.BEARIHG.VALID  -  CBOOL.CTTRUE)  T  ♦  T  ♦  ♦  ; 

(V.OTHER.RAHGE.VALID  •  ®BOOL.(nBUE)  T  a  T  *  ♦  ; 

M.POTENTIAL.THREAT.CONDITIOHa  ^  T  •  •  •  ; 

M.THREAT.COHDITIOHn  *  F  *  *  F  ; 

(SJ>T.TIHER  «  CSJ>T.O)  •  *  F  F  F  ;2 

M.P0TENTIAL.THREAT.RAN6E.TESTC]  *  *  *  F  •  ;<- 

♦a*  TABLE:  M.PROXIMATE.TRAFFIC.TO.OTHER.TRAFFICG  /  TRUE  *** 

(S.ALT.REPORTIHG  -  HS.LOST)  TTaaa***  ; 

MJUJ10DE.CAHCELLEDC]  •*TT*a*a  ;<- 

(S.ALT.REPORTIHO  -  HS.HO)  aaTTTTa  a  ;1 

(V.OTHERJEARIHG.VALID  ■  OBOOL.tmWE)  FaFaFa**  ;6 

(V.OTHER.RAHGE.VALID  ■  CBOOL.CTRUE)  aFaFaFaa  ; 

MJ>ROXIMATE.TRAFFIC.COHDmOHC]  ♦•♦•♦*Fa  ; 

MJ>OTEHTIAL.THREAT.RAHGE.TESTC]  ♦♦•♦TTaa  ; 

MJ»OTEHTIAL.THREAT.CONDITIOHa  ♦***#*Fa  ; 

H.THREAT.COHDITIOHC]  ♦♦♦♦♦♦Fa  ; 

(S.OTHER.AIR.STATUS  =  OS.STATE.OH_GROUND)  aaaaaaaT; 

aaa  TABLE:  M.POTENTIAL.THREAT.RAHGE.TEST[]  /  FALSE  aaa 

(PAIRl  <=  FJ1TA[])  a  T  ;  (3) 

(F_0THER.TRACKEDJIAHGE3ATE[]  >10)  FT;  (4) 

(F_OTHER.TRACXED.RAHGED  <=  F.DMODTAC])  a  T  ; 

(F.TAURTAC]  <  F.TRTHRTAC])  T  a  ; 


a  PAIRl  *  F_OTHER.TRA(aCED.RAHGEa  a  F.OTHER.TRACKED.RAHGE.RATECJ 


Figure  6:  Counter-example.  PAIRl  is  the  variable  that  has 
been  substituted  for  the  non-linear  expression.  The  numbers 
next  to  the  macros  denote  assertion  numbers. 

the  output  of  fewer  spurious  counter-examples.  As  an  exper¬ 
iment,  we  left  the  inequalities  uninterpreted  in  the  consis¬ 
tency  checks  between  the  transitions  Other-  Traffic  to  Threat 
and  Other- Traffic  to  Proximate- Traffic.  The  resulting  spu¬ 
rious  counter-example  required  both 

Own-Tracked- Alt- Rate  >  600 

and 

Own- Tracked- Alt- Rate  <  0 

to  be  true  at  the  same  time.  This  and  other  false  nega¬ 
tives  similar  to  it  were  not  generated  when  using  the  ftill 
capability  of  SVC. 

Having  decision  procedures  for  linear  arithmetic  also  ar 
voids  spurious  error  reports  caused  by  using  syntactically 
different  but  semantically  equivalent  formulae  in  the  speci¬ 
fication.  As  a  simple  example,  a  state  machine  in  TCAS  II 
models  whether  or  not  an  aircraft  is  descend  inhibited;  an 
aircraft  too  close  to  the  ground  is  not  allowed  to  descend. 


The  guarding  conditions  in  this  state  machine  contain  the 
predicates 

Own- Tracked- Alt  —  Ground-Level  >  1200 

and 

Own-Tracked-Alt  <  1200  +  Ground-Level. 

An  einalysis  method  without  decision  procedures  for  linear 
arithmetic  would  either  fail  to  detect  that  these  two  predi¬ 
cates  are  contradictory  and  generate  spurious  error  reports, 
or  require  formulae  to  be  in  a  standard  form. 

To  illustrate  typical  run-times  of  the  Analyzer  proto¬ 
type  tool.  Figure  7  lists  the  run-times  required  to  calculate 
the  first  counter-example  for  the  pairs  of  transitions  out  of 
Proximate-Traffic.  In  general,  the  time  required  to  find  a 
counter-example  using  the  prototype  tool  was  less  than  1 
second  of  runtime  on  a  Linux  based  Intel  Pentium  Pro  mar 
chine  and  the  time  required  to  pretty  print  took  at  most  38 
seconds.  In  comparison,  expanding  each  proof  obligation  in 
PVS  and  getting  a  counter-example  in  SVC  and  PVS  took 
roughly  5-10  minutes.  Writing  up  the  counter-examples  as 
a  list  of  macros  took  more  than  30  minutes  for  each  dis¬ 
crepancy.  Overall,  using  SVC  and  the  pretty  printer  tool 
decreas^  the  time  to  get  a  counter-example  by  several  or¬ 
ders  of  magnitude. 

The  time  required  by  SVC  to  finally  get  a  “valid”  after 
invariants  were  added  was  in  most  cases  less  than  5  minutes. 
In  one  case,  SVC  required  approximately  20  minutes.  We 
expect  that  these  numbers  could  be  significantly  lowered  by 
applying  a  number  of  extra  simplification  heuristics  in  SVC. 
Alternatively,  only  expanding  certain  selected  macros  could 
possibly  lower  these  numbers  as  well. 

The  Analyzer  prototype  tool  was  built  in  Lisp  in  less 
than  a  man  month  by  a  student  who  was  unfamiliar  with 
SVC  and  Lisp.  This  was  possible  since  we  were  able  to  call 
the  SVC  proof  engine  directly  from  Lisp.  All  computations 
of  truth  \^ues  of  RSML  formulae  were  done  in  SVC. 

6  Discussion 

The  class  of  formulae  that  SVC  decides  (quantifier  free  first- 
order  logic  with  linear  arithmetic)  was  sufiicient  for  the  part 
of  TCAS  II  that  we  checked.  Other  parts  of  TCAS  II  con¬ 
tain  non-linear  arithmetic  and  quantification  in  the  guarding 
conditions  and  therefore  can  not  directly  be  decided  by  the 
current  version  of  SVC.  We  plan  to  extend  SVC  with  new 
theories  to  handle  a  larger  class  of  formulae.  In  the  long¬ 
term,  we  can  not  expect  to  fully  automate  the  verification 
process.  A  better  strategy  would  be  to  do  as  much  automat¬ 
ically  as  possible,  but  use  a  general-purpose  theorem  prover 
to  handle  constructs  that  can  not  be  dispatched  automati¬ 
cally.  We  plan  to  use  PVS  for  this  purpose. 

Checking  local  properties  of  specifications  may  require 
global  information.  In  our  experiments,  two  invariants  were 
needed  in  order  to  discharge  the  consistency  proof  obligar 
tions.  Methods  for  extracting  such  relevant  information 
from  the  surrounding  S3rstem  are  crucial  for  application  of 
local  checks  on  a  larger  scale.  To  address  this  issue,  efficient 
invariant  generation  techniques  are  being  developed  by  the 
authors  to  detect  global  invariants  in  RSML. 

Using  SVC’s  open  interface,  we  were  able  to  quickly  build 
the  Analyzer  prototype  on  top  of  SVC,  exploiting  as  much 
functionality  of  SVC  as  possible.  In  our  opinion,  open  and 
highly  efficient  verification  tools  are  essential  for  successful 
application  of  formal  methods  to  the  verification  of  safety 
critical  systems. 


Transition 

1st  Counter-Example 

from  State 

to  States 

SVC  (msec) 

Total  (sec) 

Proximate-Traffic 

Other-Traffic  /  Threat 

10 

30.4 

Proximate-Traffic 

Potential-Threat /Threat 

20 

37.7 

Proximate-Traffic 

Other-Traffic/Pot.  Threat 

10 

24.5 

Figure  7:  Examples  of  run-times  on  an  Intel  Pentium  Pro  based  machine  running  Linux.  The  table  shows  the  pairs  of 
transitions  being  checked,  the  CPU  time  required  for  SVC  to  calculate  the  first  counter-example,  and  the  total  CPU  time  to 
calculate  and  display  the  first  counter-example. 


We  have  reported  on  an  initial  feasibility  study  of  check¬ 
ing  consistency  properties  of  RSML  specifications.  More 
effort  is  needed  to  investigate  the  application  of  formal  veri¬ 
fication  tools  to  check  other  aspects  of  RSML  specifications. 
The  long  term  goal  is  to  construct  an  integrated  RSML 
toolset.  The  SCR  toolset  [11]  is  inspirational  in  this  regard. 
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A  Analyzer  Input 


MACBO  RA^InhibitO  : 

TABLE 

Auto^L  IH^STATE  ASL_2  :  T  .  ,  ; 

Mod«_S«l«ctor  =*  TA^Only  i  .  T  .  ; 

RA^lnhlbit^From^Gromid  =  cTru«  :  .  .  T  ; 

EHD  TABLE 
END  MACRO 

B  Counter-Example 

<<<<<<<<<<<<<<<<<<<<  ANALYZER  »»»»»»»»»» 

0)  Quit 

1)  List  all  tables 

2)  View  a  table 

3)  Check  the  Talidity  of  an  expression 

4)  Check  consistency  between  transitions 

Tour  choice:  4 

Transition! :  M_PROXIMATE_TRAFFIC_TO_POTEHTIAL_tHBEAT [] 
Transition2 :  M_PROXIMATE^TRAFFIC_TO«OTHER_TRAFFIC  U 

COUNTER-EXAMPLE 


TRANSITION  Proximate.Traffic  TO  Potent lal_Thre at  : 

LOCATION  :  TCAS.Controller.Pover_On_Fully_Operational_\ 
Other  _A  ir  craft  .Tr  ack^St  at  us.Tracked^Int  ruder. St  at  us 


TRIGGER  :  Air_Status_Evaluated_Event 
CONDITION  :  TABLE 

Alt.Reporting  IN_STATE  Yes  :  F  T  F  F  T 
Other.Bearing_Valid  =  cTrue  :  T  .  T  .  . 
Other.Rai^e.Talid  *  cTrue  :  T  .  T  .  . 
Potent ial.Threat .Condition ()  :  T  T  .  .  . 
Threat.ConditionO  ;  .  F  .  .  F 
PT.Tiner  IN.STATE  PT.O  :  .  .  F  F  F 
Potent Ial.Threat .Range. Test ()  :  .  .  .  F  . 
END  TABLE 


ACTION  :  Intruder.Status.Exaluated.ETent 
END  TRANSITION 


TRANSITION  Proximate.Ttaff ic  TO  Other.Traffic  : 

LOCATION  :  TCAS.C ontr oiler. Po«er.0n_Fully.0perational.\ 

Other.Aircraft.Track.Status.Tracked. Intruder .Status 
TRIGGER  :  Air_StatusJEvaluated.£vent 
CONDITION  :  TABLE 


Alt.Reporting  IN.STATE  Lost 

T  T . 

RA.Hode.Cancelled () 

.  .  T  T  -  .  .  . 

Alt.Reporting  IN.STATE  No 

^  T  X  T  X  ,  ^ 

0ther.Bearing.Val id  «  cTrue 

F  .  F  .  F  .  .  . 

0ther.Range.Valid  «  cTrue 

.  F  .  F  .  F  .  . 

Proximate .Traf f ic .Condi ti on ( ) 

. F  . 

Potential.Threat.Range.Test () 

.  .  .  .  T  T  .  . 

Pot  ent i al .Tfar e at .Condit ion ( ) 

. F  . 

Threat.ConditionO 

. F  . 

Other.Air .Status  IN.STATE  State.On.Ground 

. T 

END  TABLE 

ACTION  :  Intruder.StatU8_E7aluatedJBTent 
END  TRANSITION 


1)  (S.ALT.REPORTING  *  €S.N0) 

2)  (NOT  (S.PT.TIMER  *  •S.PT.O) 

3)  (NOT  (PAIR!  <«  F.HlTAa)) 

4)  (F.OTHER.TRACKED.RANOE.RATEC]  >  10) 

6)  (NOT  (V.0THER.BEARIN0.VALID  =  CBOOL.CTRDE) ) 

6)  (NOT  (V_PREV.RA.IHHIBIT  «  CBOOL.CTRDE)) 

7)  (S.ADTO.SL  -  CS.ASL.2) 


***  TABLE:  M.PROXIMATE.TRAFFIC.TO_POTENTIAL.THREATC]  /  TRUE  ••• 


(S.ALT.REPORTIHG  •»  CS.YES) 
(V.OTHER.BEARING.VALID  »  CBOOL.CTRDE) 
(V.OTHERJUHGE_VALID  =  CBOOL.CTRDE) 
M.P0TENTIAL.THREAT.C0HDITI0N  □ 
M.THREAT.C0MDITI0N  C] 

(S  J»T.TIRER  ■  CS.PT.0) 
M.POTEimAL_THREAT.RANCE_TEST  [] 


F  T  F  F  T  ;1 

T  •  T  *  •  ; 

T  ♦  T  ♦  ♦  ; 

T  T  ♦  *  •  ; 

»  F  ♦  ♦  F  ; 

»  ♦  F  F  F  ;2 
♦  *  ♦  F  ♦  ;<- 


TABLE:  M.PR0XIMATE.TRAFFIC.T0 .OTHER.TRAFFIC □  /  TRUE 


(S.ALT_REPORTIHG  *  CS.LOST)  TT******; 

M.RA.MODE_CANCELLEDC]  ♦♦TTe**#;<- 

(S.ALT.REPORTING  *  CS.NO)  **TTTTe*;l 

(V.OTHER.BEARIHG.VALID  «  CBOOL.CTRDE)  F*FeF***;6 

(V.0THER.IUN6E.VALID  •  CBOOL.CTRDE)  eFeFeFe*; 

M.PROXIMATE.TRAFFIC_CONDmON[]  ♦♦**eeFe; 

M.POTEHTIAL.THREATJUNOE.TESTC]  ♦•♦*TT»e  ; 

M.P0TENTIAL.THREAT.C0NDITI0Na  ♦♦♦♦•♦F*; 

H.THREAT_C0HDITI0NC3 

(S_0THER.AIR.STATDS  -  CS.STATE.ON.GRODND)  ♦♦♦****T; 


♦♦♦  TABLE:  M.POTENTIAL_THREAT.RANGE.TESTC]  /  FALSE 


MACRO  Pot ential.Threat .Range. Test ()  : 

TABLE 

(Other .Tracked.Range 0  * 

Other.Tracked.Range.Rate())  <»  HITAO  :  .  T 
Other.Tracked.Range.Rate  0  >  RDTHRTA  :  F  T 

Other.Tracked.Range()  <■  DMODTAO  :  .  T 

TADRTAO  <  TRTHRTAO  :  T  . 

END  TABLE 
END  MACRO 


MACRO  RA.Mode.Cancelled()  : 
TABLE 

RA.InhibitO  :  T  ; 

PREY.RA. Inhibit  *=  cTrue  :  F  ; 
END  TABLE 
END  MACRO 


(PAIR!  <-  F.H1TAC3)  ♦  T  ; (3) 

(F.0THER.TEACKED.RAN0E.RATEC]  >10)  FT;  (4) 

(F_0THER.TRACKEDJIANGE[3  <«  F.DMODTACl)  »  T  ; 

(F_TAURTAC3  <  F.TRTHRTAC3)  T  ♦  ; 


TABLE:  M.RA.M0DE.CANCELLED[]  /  TRUE 

M.RA.IHHIBITn  T  ;<- 

(V.PREV.RA.IBHIBIT  «  CBOOL.CTRDE)  F  ;6 


»♦*  TABLE:  M.RA.IHHIBITn  /  TRDE 

(S.ADTO.SL  =  CS.ASL_2)  T  ♦  *  ;7 

(VJH0DE.SELECT0R  ■  CMODE.TA.ONLY)  *  T  •  ; 

(V.RA.INHIBIT.FR0M.GR0DND  -  CBOOL.CTRDE)  •  ♦  T  ; 


♦  PAIRl  “  F_0THER_TRACKED_RANGEC3  ♦  F_0THER_TRACKED.RANGE.RATEC3 
♦♦  Two  global  invariants  rule  out  the  previous  counter-examples. 


C  RSML  Example 


'I!rCL]lSltlOn(s)l  |  Proximate-lVaffii^  — ^  \  Potential-Threat 
Location:  Other- Aircraft  >  Intruder-StatuSs_i54 


Trigger  Event:  Air-Status-Evaluated-Evente-396 
Condition: 


OR 


Alt-Reportingg.148  in  state  Yes 

F 

T 

F 

F 

T 

Other-Bearing- Validy.i  33  =  TVue 

T 

T 

Other-Range- Validy.i  30  =  True 

T 

T 

Potential-Threat-Conditionin.288 

T 

T 

Threat-Conditionni-305 

~W 

T" 

PT-Timer8-240  state  0 

• 

Z 

F 

F 

Potential-Threat-Range-Testm-28  9 

F 

Output  Action:  Intruder-Status-Evaluated-Evente-396 


Transit ion(s):  |  Proximate-Traffic  |  — ►  |  Other-Traf^ 
Location:  Other- Aircraft  >  Intruder-StatuSg_i54 


Trigger  Event:  Air-Status-Evaluated-Evente-396 
Condition: 


OR 


Alt-Reportingg_i48  in  state  Lost 

T 

T 

RA-Mode- C  an  celledm- 1 6 1 

T 

T 

Alt-Reporting8_i48  in  state  No 

T 

T 

T 

T 

Other-Bearing- Validy-133  =  True 

F 

F 

F 

Other-Range- Validy.130  =  True 

F 

F 

• 

F 

Proximate'Traffic-Condition,„.292 

• 

• 

F 

Potential-Threat-Range-Test  in.289 

T 

T 

Potential-Threat-  Condition  jn-288 

“F 

Threat-Conditionni,305 

F 

Other-Air-StatuSg.148  in  state  On-Ground 

T 

Output  Action:  Intruder-Status-Evaluated-Eventg_3gg 


Macro:  Potential-Threat-Range-Test 

Definition: 

A 
N 
D 


01 

R. 

Other-Tracked-Rangef_347  *  Other-Tracked-Range-Rate|r_34g  <  HlTA 

T 

Other-'l>acked-Range-Ratef_34g  >10  ft/S(RDTHRTA) 

F 

T 

Other-Tracked-Rangef_347  <  DMODTA 

T 

TAURTA  <  TRTHRTA 

Macro;  RA-Mode-Cancelled 
Dranition: 


A 


RA-Inhibitnj_293 

T 

PRE  V(R  A-Inhibit  m-293  ) 

F 

Macro;  RA-Inhibit 
Definition: 


OR 


AutO-SLg_3]^  In  state  2 

T 

Mode-SeIectory_36  =  TA.Only 

T 

RA-Inhibit-From-Groundjjj.293 

T 

